The patch seems right, but I wonder why you need to know this in RINIT?

but I wonder why you need to know this in RINIT?

My use case includes a fairly expensive and ultimately useless startup phase if no script is actually executed.

In fact such a use case also exists within PHP itself: ext/session when combined with session.auto_start=1. It will perform all the session startup logic, including the creation of a new session, even when just syntax checking a file:

$ strace -eopenat sapi/cli/php -d session.auto_start=1 -l test.php 2>|grep sess_
openat(AT_FDCWD, "/tmp/sess_92830e591ed498cc8897b62d18c1dcab", O_RDWR|O_CREAT|O_NOFOLLOW, 0600) = 4
No syntax errors detected in test.php

Okay I see. However in that case I don't think this patch is entirely right. The server mode of the CLi SAPI does use server_context to store client data. How is your RINIT code gonna know which data structure is stored in the context?

The CLI Server uses cli-server as the SAPI name:

Will this need a docs update about cli mode? It's already quite special: https://www.php.net/manual/en/features.commandline.differences.php

Will this need a docs update about cli mode? It's already quite special: https://www.php.net/manual/en/features.commandline.differences.php

I don't see what the docs have to do with this change? This is an internal change to the SAPI, the docs cover userland.

I don't see what the docs have to do with this change? This is an internal change to the SAPI, the docs cover userland.

@TimWolla said:

In fact such a use case also exists within PHP itself: ext/session when combined with session.auto_start=1. It will perform all the session startup logic, including the creation of a new session, even when just syntax checking a file

Until I looked at the diff a little deeper, I thought this would affect that now. In other words, if someone were relying on that kind of behavior, it might break.